Software programs or applications typically include several different functions, modules, methods, etc. (i.e., “units”) that interact by accessing and using shared resources. Generally speaking, a unit may be described as the smallest testable portion of an application such as a function or procedure. On a larger scale, applications themselves are written so that other programs may be written to access and use the application's resources. To understand existing applications and to develop new applications that add functionality to these existing applications, an application programming interface (API) is often developed to aid future development. An API defines the rules and specifications for a software program so that other programs can be designed to use the various resources of that program. In other words, the API operates as an interface between programs.
To assist other programmers in creating compatible programs, each application typically includes an API while the source code for each unit within the application includes comments that describe the unit. For example, the comments may generally describe the classes, methods and objects within a unit of the source code as well as the inputs and outputs expected during that unit's execution. In conjunction with the API, these unit comments may guide developers as they write compatible applications or expand the application.
However, an API may be difficult and time-consuming to write. As the complexity of the source code grows, an API accessing the source code will also become more complex. Numerous systems may automatically generate APIs and other documentation in a common format (e.g., HTML) directly from the API's source code. For example, commercial tools like Javadoc (“JDoc”) from Oracle Corporation, or open source tools such as JSDoc and Doxygen parse the source code and source code comments into hyperlinked HTML API documents.
In addition to the API, testing is often necessary to develop effective and efficient computer code. The process of testing code typically includes, but is not limited to, testing units of the application in isolation from the other units of the application as the programmer writes the source code for the application. Testing normally involves writing a short test application that utilizes the code that is the subject of the test. This short application includes a rigorous contract that the test subject source code must satisfy when it is executed. If the test is written correctly and the contract is satisfied, then the developer is more confident that the test subject source code will perform correctly for any other user or developer. Testing usually proceeds in isolation for each unit of the source code to reduce the likelihood that one developer creates the same error in both the implementation and the test application. Further, if all units of an application pass the unit tests in isolation, then the application as a whole is more likely to execute as desired when all units are included.
While several tools exist to automatically write an API for a finished application, unit tests are written by the developer in the same manner as the source code, often while the source code for the unit is written, or at some time after the source code is finished. As an application increases in complexity, the number of unit tests required increases. Because developers must write each unit test in the same manner as the source code, unit testing becomes a tedious and complex process for even the simplest of applications. Understanding whether testing for complex applications that include many testable units is successful or complete can also be confusing and time consuming.